"Operational methods" are methods that communicate with the target environment (OPC servers etc.), directly or indirectly. Auxiliary methods, which may also exist on the objects, are not listed here.

Many methods exist in two forms:

• Single-operation.
• Multiple-operations.

In OPC, operations are much more effective if performed together in a group, at once. For example, doing a read of 100 values is much faster if performed at once, using the multiple-operation method, instead of repeatedly calling the single-operation method in a loop. For this reason, you should use the multiple-operation methods whenever possible. An exception to this rule are methods that act as substitute for event handlers (these methods are consistently named PullXXXX), where the recommendation is the opposite - you should normally use the single-operation method form instead.

Operational method naming conventions

The name of the operational method usually consists of a verb that denotes what the method does, and sometimes a noun which describes either the affected entity (such as in "ReadItem", or the outcome of the method (such as in "BrowseObjects").

Usually, the name of the multi-operation method is derived from the name of the single-operation method by using a plural instead of singular form of the noun (if it is present), and preceding the noun it with "Multiple" (or adding it at the end, when the noun is missing). For example, "ReadItem" becomes "ReadMultipleItems", and "Write" becomes "WriteMultiple". Such methods use an array of argument objects (one for each operation) as an input, and return an array of results (one for each operation again); the indexes in the output array correspond to the indexes in the input array.

When an input or output array is replaced by a list in the method signature, a word "List" appears at the end of the method name. This happens with all multiple-operation methods (where the word "Multiple" is removed then), and also with some single-operation methods where the argument or result happens to an array already.

Legend to the tables

This chapter explains some of the notation used in the tables that follow:

• bold
• italics
• grayed out

When two or more methods appear in the table cell on the same line, separated by a comma, they perform precisely the same function, but differ only in the form of arguments accepted or results returned. Typically, this is with method that work with lists, that ar in addition to methods that work with arrays.

When multiple lines with different methods are listed inside a single table cell, then other methods with slightly different purpose are all derived (by extension) from the primary method listed in bold. This grouping helps you to understand the internal relations of the methods, where only a handful of primary methods is used to provide richer functionality, by means of method overloads, or methods with different names. The primary method is always the most general one and can always be used. It is, however, often more convenient to use the derived methods, which are more specialized, and give shorter and more understandable code.

Methods listed in the tables here are considered (unless stated otherwise), for the purpose of the explanation in this document to be methods of the objects listed even though (in .NET) in reality, they may be implemented as extension methods on the object or interface. They are also generally available under COM development platform, on the respective COM interfaces. There are other sets of extension methods, for .NET only, which further enhance the functionality of listed objects. These extension methods are not listed here, but rather under Layered Extensions for .NET and Python.

Methods that are only available on the COM development platform are listed in italics. They are currently methods that accept or return lists instead of arrays, which is a necessity for some COM tools or languages that lack a sufficient support for COM safe arrays.

Methods that primarily exist for internal implementation (infrastructure) reasons are grayed out, and you should not normally used them.

EasyDAClient operation methods

This object is for OPC Data Access (OPC "Classic", COM/DCOM-based) and for OPC XML-DA.

EasyAEClient operation methods

This objects is for OPC Alarms and Events (OPC "Classic", COM/DCOM-based).  

EasyUAClient operation methods

This object is for OPC Unified Architecture (OPC UA).